Ensuring security in a distributed computing environment is becoming increasingly complex. As soon as a security hole is detected and patched, another vulnerability is detected. Traditionally, security is enforced at various levels of abstraction within a distributed environment. For example, the Operating System (OS) is layered and includes a File System (FS) or Directory System (DS). Both the OS and the DS employ security techniques to prevent unintentional or malicious damage to the resources (e.g., hardware and/or software) of the distributed environment.
In order to decrease the coding complexity of conventional DSs, the DSs are modularized at various levels of abstraction similar to the design of OSs. Accordingly, some DSs use Object Oriented (OO) design and programming methodologies. In an OO approach, resources (physical and logical), organizations, applications, users, geographic locations, and the like are encapsulated as object entities within a software module. The objects include publicly available access methods and privately available access methods. The private methods are used, in part, to enforce some security since only internal or authorized users, objects, and/or applications are permitted to process the private methods. The private methods also permit the objects to hide lower levels of coding abstraction that are associated with the objects. The public methods are published and accessible to other users, objects, and/or applications and are used to communicate with the object.
Objects also include attributes or properties that can be set or accessed through a number of the public methods associated with the objects. For example, a DS object representing a user can include an attribute called GroupMembership, where one or more values assigned to the GroupMembership attribute represent other objects and/or object groups to which the user belongs. The user object can also include an attribute that identifies the directory in which the user is to be placed upon login. Moreover, as is readily apparent to one of ordinary skill in the art, a single object can be a superset of aggregation of a multitude of other objects.
Although the OO approach for DSs implementations can enforce security attributes for accesses to the objects a security hole is readily detected. For instance, a modifier (e.g., user, application, or another object) can generate an instance of an object. The modifier has access to generate the instance of the object. While defining the instance, the modifier can provide a value for an attribute of the instance. The value can be a hard coded string constant to a different object. Moreover, the different object can be a destructive operation, such as a format hard drive operation. Furthermore, the attribute of the instance can include a forced execution value, such that the modifier can assign the format hard drive operation and force its execution upon login of a user. Conventionally, the values provided for attributes are not validated to ensure that the values are not references to other objects that the modifier is not permitted to access.
The security hole is particularly noticeable when two or more systems are interfaced with one another and have access to the same object. For example, a first system, such as a calendaring system, may permit a user with proper access rights to a conference room to freely invite other users to attend a meeting in the conference room. The conference room is represented as an object within the first system, and the conference room can include a plurality of attributes such as direction information, time-of-day limitations, date limitations, invited attendees, and the like. The calendar object can also be interfaced to other systems, such as email systems, word processing systems, and/or systems that permit values of attributes defined within the calendar object to trigger the automatic execution of an external application. With conventional designs and approaches it would be perfectly permissible for a user to invite attendees to a meeting in the conference room, since on the surface this appears to be an innocuous operation (e.g., not actually modifying an attendee's calendar). But, if values provided as attributes of the conference room are also linked with other systems, such that external applications can be automatically launched, then the user could achieve something typically not permissible. For example, the user could forcibly place an entry on an attendee's calendar, or the user could do something more destructive, such as using a second system to launch a destructive application that could do damage to resources of an attendee.
As is now apparent, there exists a need for improved techniques that enforce security on attributes of objects. This is particularly useful when objects are used by two or more different systems. Furthermore, the techniques should be flexible, practical, easy to manage, integrate, and implement.